Middleware may be used to implement a real-time data distribution system to allow distributed processes to exchange data without concern for the actual physical location or architecture of their peers. The middleware may include support for best-effort and reliable communications. For example, the Object Management Group's (OMG) Data Distribution Service for Real-Time Systems (DDS) is a standard specification for publish-subscribe data-distribution systems. The purpose of the specification is to provide a common application-level interface that clearly defines the data-distribution service.
Referring to the simplified block diagram in FIG. 1, DDS uses a publish-subscribe (P-S) communication model. The P-S communication model employs asynchronous message passing between concurrently operating subsystems. The publish-subscribe model connects anonymous information producers with information consumers. The overall distributed system is composed of processes, each running in a separate address space possibly on different computers. In this patent application, each of these processes of the distributed system is referred to as a “participant application”. A participant application may be a producer or consumer of data, or both.
Using the middleware, data producers declare the topics on which they intend to publish data; data consumers subscribe to the topics of interest. When a data producer publishes some data on a topic, the middleware operates such that all the consumers subscribing to that topic receive it. The data producers and consumers remain anonymous, resulting in a loose coupling of sub-systems, which is well suited for data-centric distributed applications. This is referred to as a DCPS (data-centric publish subscribe) architecture.
The DCPS model employs the concept of a “global data space” of data-objects that any entity can access. Applications that need data from this space declare that they want to subscribe to the data, and applications that want to modify data in the space declare that they want to publish the data. A data-object in the space is uniquely identified by its keys and topic, and each topic has a specific type. There may be several topics of a given type. A global data space is identified by its domain id. Each subscription/publication belongs to the same domain to communicate.
For example, the reader is referred to the Object Management Group's Specification entitled “Data Distribution Service for Real-Time Systems Specification,” Version 1.1, dated December 2005. See http: //www dot omg dot org/docs/formal/05-12-04 dot pdf (referred to herein as “DDS Specification”). In the DDS Specification, a DCPS architecture is specified that includes the following entities: DomainParticipant, DataWriter, DataReader, Publisher, Subscriber, and Topic. All these classes extend Entity, which is an abstract base class for all the DCPS objects that support QoS policies, a listener and a status condition. The particular extension of Entity represents the ability to be configured through QoS policies, be enabled, be notified of events via listener objects, and support conditions that can be waited upon by the application. Each specialization of the Entity base class has a corresponding specialized listener and a set of QoSPolicy values that are suitable to it. See FIGS. 2-2 (“DCPS conceptual model”) of the DDS Specification.
A Publisher represents the object responsible for data issuance. A Publisher may publish data of different data types. A DataWriter is a typed facade to a publisher; participants use DataWriter(s) to communicate the value of and changes to data of a given type. Once new data values have been communicated to the publisher, it is the Publisher's responsibility to determine when it is appropriate to issue the corresponding message and to actually perform the issuance (the Publisher will do this according to its QoS, or the QoS attached to the corresponding DataWriter, and/or its internal state).
A Subscriber receives published data and makes it available to the participant. A Subscriber may receive and dispatch data of different specified types. To access the received data, the participant must use a typed DataReader attached to the subscriber.
The association of a DataWriter object (representing a publication) with DataReader objects (representing the subscriptions) is done by means of the Topic. A Topic associates a name (unique in the system), a data type, and QoS related to the data itself. The type definition provides enough information for the service to manipulate the data (for example serialize it into a network-format for transmission). The definition can be done by means of a textual language (e.g. something like “float x; float y;”) or by means of an operational “plugin” that provides the necessary methods.
The DDS middleware handles the actual distribution of data on behalf of a user application. The distribution of the data is controlled by user settable Quality of Service (QoS).
Real-time middleware should be characterized by predictable delivery of data. The middleware of a node thus buffers incoming data samples until an application executing on the node retrieves the data samples. In addition, the middleware buffers outgoing data samples, for example, in case they need to be resent to one or more readers according to an applicable QoS. Storing data samples requires memory, and the amount needed changes dynamically.